There are now two project a project in CC's cvs for this:
Projects/XPCOM/Xul18Browser
Projects/XPCOM/Xul19Browser
Those contains some code found online for embedding the browser. I changed it to try it out on mac. It should be refactored so it can be tried on all the platforms.
This bug report has lots of intresting info:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154597#c4
It has a reference to this page in webclient:
http://landfill.mozilla.org/mxr-test/mozilla/source/java/webclient/src_moz/cocoa/CocoaBrowserControlCanvas.mm#38
This bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=335696
Documents a new function added xulrunner:
long getNativeHandleFromAWT(Object widget)
This patch has been applied to xulrunner 1.8.1.2 it is also on the trunk of xulrunner. I specifically found it in version 1.9a3pre.
Taking the xul-sample.zip code on the Windows embedding page and modifying it to work with xulrunner 1.9 and to use the macosx window pointer, gives this error. This could be because there is something between 1.8 and 1.9 xulrunner that I'm not doing right.
0 XUL 0x1b678284 nsCSubstring::ReplaceASCII(unsigned, unsigned, char const*, unsigned) + 36
1 XUL 0x1b6f67ff nsJavaXPTCStub::SetupJavaParams(nsXPTParamInfo const&, XPTMethodDescriptor const*,
unsigned short, nsXPTCMiniVariant*, nsXPTCMiniVariant&, jvalue&, nsACString_internal&) + 3921
2 XUL 0x1b2400ba nsGlobalWindow::GetWebBrowserChrome(nsIWebBrowserChrome**) + 3206
3 XUL 0x1b23b9ee nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, int, int) + 648
4 XUL 0x1b23c88c nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, int, int) + 4390
5 XUL 0x1afaab1f DocumentViewerImpl::InitInternal(nsIWidget*, nsISupports*, nsIDeviceContext*, nsRect const&, int, int, int) + 951
6 XUL 0x1afaabc0 DocumentViewerImpl::InitInternal(nsIWidget*, nsISupports*, nsIDeviceContext*, nsRect const&, int, int, int) + 1112
7 XUL 0x1b3b48f4 nsDocShell::SetupNewViewer(nsIContentViewer*) + 1736
8 XUL 0x1b3aa7ea nsDocShell::Embed(nsIContentViewer*, char const*, nsISupports*) + 46
9 XUL 0x1b3b1f9f nsDocShell::CreateAboutBlankContentViewer(nsIPrincipal*) + 667
10 XUL 0x1b3b20d2 nsDocShell::EnsureContentViewer() + 142
11 XUL 0x1b3a850f nsDocShell::GetInterface(nsID const&, void**) + 455
12 XUL 0x1b3b7625 nsWebShell::EnsureCommandHandler() + 383
13 XUL 0x1b61ec23 nsGetInterface::operator()(nsID const&, void**) const + 95
14 XUL 0x1b61d737 nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) + 21
15 XUL 0x1b2322e3 nsGlobalWindow::ClearWindowScope(nsISupports*) + 221
16 XUL 0x1b0f3006 nsCopySupport::ImageCopy(nsIImageLoadingContent*, int) + 2578
17 XUL 0x1b0e7a96 nsContentPolicy::~nsContentPolicy [in-charge deleting]() + 616
18 XUL 0x1b3b4e55 nsDocShell::InternalLoad(nsIURI*, nsIURI*, nsISupports*, unsigned, unsigned short const*, char const*,
nsIInputStream*, nsIInputStream*, unsigned, nsISHEntry*, int, nsIDocShell**, nsIRequest**) + 849
19 XUL 0x1b3af85d nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned, int) + 1267
20 XUL 0x1b3acfcd nsDocShell::LoadURI(unsigned short const*, unsigned, nsIURI*, nsIInputStream*, nsIInputStream*) + 751
21 XUL 0x1b3f8dfc nsWebBrowser::HandleEvent(nsGUIEvent*) + 1334
22 XUL 0x1b6641e3 NS_InvokeByIndex + 81
23 XUL 0x1b6f39fe Java_org_mozilla_xpcom_internal_XPCOMJavaProxy_callXPCOMMethod + 1220
24 <<00000000>> 0x0457a1d1 0 + 72851921
25 <<00000000>> 0x045749ea 0 + 72829418
26 <<00000000>> 0x04574cf0 0 + 72830192
27 <<00000000>> 0x04574c19 0 + 72829977
28 <<00000000>> 0x04574a6b 0 + 72829547
29 <<00000000>> 0x04574913 0 + 72829203
30 <<00000000>> 0x04574913 0 + 72829203
31 <<00000000>> 0x0457215d 0 + 72819037
32 libclient.dylib 0x9b32a2a6 jio_snprintf + 397048
33 libclient.dylib 0x9b329ff4 jio_snprintf + 396358
34 libclient.dylib 0x9b34648b JVM_MaxMemory + 7279
35 libclient.dylib 0x9b3921d2 JVM_FindLoadedClass + 2292
36 java 0x00003d30 0x1000 + 11568
37 java 0x00004560 0x1000 + 13664
38 libSystem.B.dylib 0x90023d87 _pthread_body + 84
Running CXul in Xul18Browser, causes assertions becuase some of the moz code is being called in different threads. The problem seems to be that the main setup can happen either in the main thread or the awt event thread. But then a native paint event is sent to the nsBaseWidget in thread 1, which is aparently different than the main thread. Here is the stacktrace of the paint event. So somehow it seems we need to make the DeviceContext creation happen on thread 1.
#0 DeviceContextImpl::AddRef (this=0x3bb1a9c0) at nsDeviceContext.cpp:54
#1 0x240f3c5a in ns_if_addref<nsIDeviceContext*> (expr=0x3bb1a9c0) at ../../dist/include/xpcom/nsISupportsUtils.h:114
#2 0x23f77988 in nsRenderingContextMac::Init (this=0x3bb1e2a0, aContext=0x3bb1a9c0, aWindow=0x3bb1a850) at nsRenderingContextMac.cpp:135
#3 0x23fb3155 in nsBaseWidget::GetRenderingContext (this=0x3bb1a850) at nsBaseWidget.cpp:615
#4 0x23faa822 in -[ChildView drawRect:] (self=0x3bb1ab30, _cmd=0x90aa4bac, aRect={origin = {x = 0, y = 0},
size = {width = 500, height = 488}}) at nsChildView.mm:2425
#5 0x932fe3b1 in -[NSView _drawRect:clip:] ()
#6 0x932fd40b in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#7 0x9330f36f in _recursiveDisplayInRect2 ()
#8 0x9083cb70 in CFArrayApplyFunction ()
#9 0x932fd613 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#10 0x9330f36f in _recursiveDisplayInRect2 ()
#11 0x9083cb70 in CFArrayApplyFunction ()
#12 0x932fd613 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#13 0x932fc473 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#14 0x932fd041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#15 0x932fbb78 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#16 0x932fb362 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#17 0x932fac8e in -[NSView displayIfNeeded] ()
#18 0x932faa32 in -[NSWindow displayIfNeeded] ()
#19 0x9b686bfc in -[CocoaAppWindow displayIfNeeded] ()
#20 0x9334ad6c in _handleWindowNeedsDisplay ()
#21 0x9082bdae in __CFRunLoopDoObservers ()
#22 0x9082ae50 in CFRunLoopRunSpecific ()
#23 0x9082ab0e in CFRunLoopRunInMode ()
#24 0x92ddabef in RunCurrentEventLoopInMode ()
#25 0x92dda2fd in ReceiveNextEventCommon ()
#26 0x92dda154 in BlockUntilNextEventMatchingListInMode ()
#27 0x9327f465 in _DPSNextEvent ()
#28 0x9327f056 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#29 0x93278ddb in -[NSApplication run] ()
#30 0x9b67f340 in +[AWTStarter startAWT:] ()
#31 0x92611489 in __NSFireMainThreadPerform ()
#32 0x9085e399 in __CFRunLoopPerformPerform ()
#33 0x9082afd2 in CFRunLoopRunSpecific ()
#34 0x9082ab0e in CFRunLoopRunInMode ()
#35 0x000046f8 in ?? ()
#36 0x00001f06 in ?? ()
#37 0x00001e2d in ?? ()
Inorder to solve this, my current thinking is that I need to make a native wrapper NSView. Which is then used with a CocoaComponent class in java. The wrapper actually calls back to java when it is getting setup on thread 1. This is where the mozilla setup will occur. Then all changes to mozilla need to done if proxy methods if they are done from the awt event thread. This means we'll have to make sure the proxy listener is correctly running on thread 1.
My current thinking is that I need to make a war
Posted by pburney at Mar 14, 2007 19:40
